crates/gitlawb-node/src/api/repos.rs (1)

443-445: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Fix the authorization invariant wording.

Line 444 says read access is a subset of push access, but the intended invariant is that a legitimate pusher also has read access. The current wording is backwards and could mislead future auth changes.

Suggested wording

-    // git-receive-pack POST; read access is a strict subset of push access, so a
-    // legitimate pusher (the owner) always clears this gate.
+    // git-receive-pack POST; push access implies read access here, so a
+    // legitimate pusher (the owner) always clears this gate.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/gitlawb-node/src/api/repos.rs` around lines 443 - 445, The
authorization comment in repos.rs is using the wrong invariant wording: it
currently says read access is a subset of push access, but it should state that
a legitimate pusher also has read access. Update the nearby explanatory comment
around the push/read gating logic in the repos.rs authorization flow so it
clearly reflects that push implies read for the owner, and keep the wording
aligned with the existing owner-gated git-receive-pack behavior.

crates/git-remote-gitlawb/src/main.rs (1)

323-327: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Correct the receive-pack POST gate description.

These lines say git-receive-pack POST also runs the read visibility gate, but the node-side contract describes receive-pack POST as separately owner-gated. Keep the comment aligned with the actual cross-layer auth contract.

Suggested wording

-/// services. The node read-gates the git-upload-pack POST as well as the
-/// git-receive-pack POST (each runs visibility_check at "/"), and the Phase-1
-/// advertisement signature does not carry to this separate request — so a private
+/// services. The node read-gates the git-upload-pack POST and separately
+/// owner-gates the git-receive-pack POST; the Phase-1 advertisement signature
+/// does not carry to this separate request — so a private

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/git-remote-gitlawb/src/main.rs` around lines 323 - 327, The comment in
the Phase-2 pack POST flow is describing the receive-pack auth gate incorrectly;
update the wording near the code that builds and signs the POST in main.rs to
reflect that git-receive-pack is owner-gated separately, not
read-visibility-gated like git-upload-pack. Keep the explanation aligned with
the actual cross-layer auth contract by distinguishing the two request paths and
preserving the note that the Phase-1 advertisement signature does not apply to
this separate request.

crates/gitlawb-node/src/api/mod.rs (1)

367-393: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Recurse into nested API modules in the completeness scan.

This loop only inspects direct src/api/*.rs entries. A future src/api/<module>/mod.rs or nested .rs file can add a repo-scoped handler without ever tripping this “whole new module” guard, so the guarantee in the comment is currently broader than the implementation.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/gitlawb-node/src/api/mod.rs` around lines 367 - 393, The completeness
scan in the API guard only checks direct files from `src/api`, so nested modules
like `mod.rs` under subdirectories can bypass the repo-scoped handler check.
Update the test logic around the `sources`, `listed`, and `handler_names` scan
to recurse through subdirectories under `src/api` and inspect all `.rs` files
except the top-level module entrypoint. Make sure the assertion that rejects
unlisted repo-scoped handlers applies to every discovered API source, not just
immediate children.

crates/gitlawb-node/src/api/mod.rs (1)

429-450: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Basename-only listed match risks masking a same-named nested file.

listed.contains(fname.as_str()) (Line 436) skips by bare filename. If a future nested module reuses a basename already present in the top-level sources list (e.g. api/<module>/repos.rs alongside the existing top-level api/repos.rs), the nested file would be silently skipped even though it's a distinct, unscanned file — defeating the completeness guarantee the recursive walk was added for. Comparing the file's path relative to api_root against the listed entries (which are also bare names today, so this would need the sources declarations to carry relative paths too) would close this gap.

♻️ Possible hardening direction

-            if path == api_root.join("mod.rs") || listed.contains(fname.as_str()) {
+            let rel_str = rel.to_string_lossy();
+            if path == api_root.join("mod.rs") || listed.contains(rel_str.as_ref()) {
                 continue;
             }

(Requires sources entries to store paths relative to api_root rather than bare filenames, or an equivalent path-aware lookup.)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/gitlawb-node/src/api/mod.rs` around lines 429 - 450, The recursive
scan in the api guard is using a basename-only check in the `collect_rs_files`
loop, so a nested module can be skipped if it reuses a filename already present
in `listed`. Update the lookup in `crates/gitlawb-node/src/api/mod.rs` to
compare paths relative to `api_root` instead of `fname`, and make the
`sources`/`listed` entries path-aware as needed so `api/<module>/...` files are
not silently excluded. Keep the repo-scoped handler assertion in the same loop
over `collect_rs_files`, but ensure it only skips exact matching entries, not
same-named files in different directories.